(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



4 



CORRECTED VERSION 



(19) World Intellectual Property Organization 

Iniernationai Bureau 




(43) International Publication Date (10) International Publication Number 

25 May 2(K)1 (25.05.2001) pcj WO 01/37139 Al 



(5f ) International Patent Classification G06F 17/30. 

15/16 

(21) International Application Number: PCTAJSOO/31601 

(22) International Filing Date: 

16 November 2(X)0(16.1 1.2000) 

(25) Filing Language: English 

(26) Publication Language: English 

(30) Priority Data: 

60/165,917 17 November 1999(17.11.1999) US 

(71) Applicant: PLANETEXCHANGE.COM, INC. 

lUS/USl; 700 S. Henderson Road. King of Prussia. 
PA 19406 (US). 



(72) Inventors: EFTIS, Paul. S.; 6800 Woodstone Place. 
Alexandria. VA 22306 (US). PANASHCHENKO, Oleg: 
813 Quince Orchard Boulevard #34, Gaithersbure. MD 
20878-1619 (US). 

(74) Agents: MOTTES, Andrew, J. et al.; Akin, Gump, 
Strauss. Hauer & Feld. L.L.R, One Commerce Square. 
22nd floor. 2005 Market Sueei, Philadelphia. PA 
19103-7986 (US). 

(81) Designated States (na(ional)i AE. AG. AL, AM, AT, AU, 
AZ, BA, BB. BG, BR, BY, BZ, CA, CH. CN. CR, CU. CZ, 
DE. DK, DM, DZ, EE. ES, FI, GB. GD, GE, GH. GM, HR. 
HU. ID. IL, IN, IS. JP, KE, KG, KP KR, KZ, LC LK. LR, 
LS, LT, LU. LV, MA. MD. MG, MK. MN, MW, MX, MZ. 
NO, NZ. PL, PT, RO, RU, SD. SE. SG, SI, SK, SL.TJ,TM, 
TR, rr, TZ. UA, UG, UZ, VN, YU, ZA, ZW. 

[Continued on next page] 



(54) Title: SYSTEM AND METHOD FOR MAIISTTAINING PRESENCE AND COMMUNICATING OVER A COMPUTER NET- 
WORK USING THE HTTP PROTOCOL 



10/ 



24 



DATABASE 



28 • 





cs 


JWS 






ALT 






SOCK 



Jl 



26 



PP 



Jl 



20 



GATEWAY 




LAPTOP 




COMPUTER 
WORKSTATION 




PDA 



WEB PAGE 



(57) Abstract: A computer-implemented process facilitates 
communication with an entity (18) over a network. A static 
HTTP URL is associated with the entity (18). Communications 
information reflecting ihe entity's (18) current online presence 
including the entity's (18) dynamic session information 
as determined using the HTTP protocol is linked with the 
URL. Communication with the entity (18) is facilitated 
using the URL and the communications information. The 
forms of communication i'aciliiated include type chat/instant 
messaging, voice communication over a computer network, 
video communication over a computer network, voice 
communication from a computer network to a telephone 
network and two-way lexi messaging to Internet enabled 
wireless devices. 



yNEB PAGE 



wo 01/37139 Al lilHlliililillUinifllililliii 



(84) Designated States (regionafj: ARIPO patent (GH. CM, 
ICE. LS. MW, MZ. SD, SL. SZ. TZ. UG, ZW), Eurasian 
paicni (AM. AZ, BY, KG, K2, MD. RU.TJ.TM). European 
paicm (AT. BE, CH, CY, DE, DK. ES. Fi, FR, GB, OR, IE, 
IT LU, MC, NL. FT. SB, TR). OAPI patent (BE BJ. CP, 
CO. CJ. CM, GA. GN, GW. ML. MR. NE, SN, TD, TG). 



Published: 

— with intemational search report 



(48) Date of publication of this corrected version: 

23 May 2002 

<I5) Information about Correction: 

see PCT Gazette No. 21/2002 of 23 May 2002, Section II 

For Two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



wo 01/37139 



PCT/USOO/31601 



TITLE OF THE INVENTI ON 

System and Method for Maintaining Presence and 
. Communicating over a Computer Network Using the HTTP Protocol 

COPYRIGHT NOTICE AND AUTHORIZATION 
Portions of the documentation in this patent document contain material 
that is subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent docimient or the patent disclosure as it 
appears in the Patent and Trademark Office file or records, but otherwise reserves all 
copyright rights whatsoever 

BACKGROUND OF THE INVENTION 

The present invention relates generally to a system and method for 
maintaining presence and conununicating over a computer network using the HTTP 
protocol. More particularly, the present invention relates to a system and method for 
maintaining communications information reflecting current online presence including 
dynamic session information as detmnined using the HTTP protocol and using the 
conmiunications information to facilitate communication over the computer network. 

The usage of computer netwoiics» particularly the Internet, has grown 
dramatically and is expected to continue to grow at a rapid pace. This surge in network 
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usage has brought with it a conesponding increase in the prevalence and importance of 
real-time networic communications methods such as instant messaging / type chat, voice 
over Internet protocol (VoIP) and video over Internet protocol These meAods and 
similar ones will play an increasingly important role in the way computers and people 
S communicate. 

In order for two computers to communicate using the Internet, a calling 
computer must know or be able to discover at least an Internet Protocol (IP) address of a 
callee. The Domain Name System (DNS) facilitates this process by resolving (i.e., 
translating or converting) a "friendly name** (i.e., a recognizable set of characters rather 

10 than a numerical IP address) into a correspondmg IP address. Thus, human users 

generally do not need to know or even see the undoiying IP address associated witfi 
computers connected to the Internet or other computer networks. 

Many Internet users access the network using a personal computer (PC) 
and an Internet Service Provider (ISP). It is a common practice for an ISP to dynamically 

IS assign an IP address that is valid only during the int^al in which the PC is connected to 
the ISP. Furthermore, there is no static identifier associated with the computer and 
available through DNS. Accordingly, in many instances, users do not know their own 
dynamically assigned Internet address, nor do they have a DNS name assigned to their 
computer. As a result, most Internet users are imable to supply any static, unique 

20 identifier that can be repeatedly used to establish a communications session with their 
computer via the Intemet 

A mechanism referred to as User Location Service (ULS) provides one 
solution to this problem. ULS includes a dynamic directory containing records tiiat map 
some uniqi^ user identifier to a currently assigned IP address. ULS places no restriction 

25 (other tiian uniqumess) on the selected static name. Individual computers are responsible 
for contacting and logging in to a ULS s^er. The act of logging in causes a new ULS 
record to be created. The ULS record is deleted when the conq>uter logs out of ULS or 
fails to continue to refresh its record. 

Two significant problems with ULS are its inability to scale and the 

30 completely non-standard way in i^ch static ruunes are resolved to IP addresses. Using 
non-standard name resolution techniques prevents pre-existing applications fix>m 

•2- 
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accessing intermittently connected devices in an autonmted manner. For example, a ULS 
identifier string cannot be resolved by DNS or by an individual's web browser software. 
Existing applications such as web browsers are typically only able to access resources 
using local file names, actual IP addresses, and DNS names. To contact intermittently 
5 connected devices using prior art techniques, the particular ULS server containing the 
address must be contacted to resolve the address. Thus, ULS registered devices are 
typically not directly accessible using many existing 2q[>pIications. 

The inability to scale well presents even greater problems. A computer 
wishing to resolve a ULS name has no way of knowing which ULS site may currently 

10 contain the proper record. There is no central authority under which all existing ULS 

sites may be automatically searched. Consequently, an exhaustive search of all available 
ULS sites is cturrently required. Worse yet, there is no current mechanism by which an 
application can determine the total set of ULS sites on a given day. Thus, newly added 
sites only further complicate an effort to locale a user having an unknown ULS 

IS connection. 

Dynamic DNS provides another solution. Dynamic DNS is very similar to 
ULS, except that dynamic DNS associates a static domain name (e.g., usemame.ddns jiet) 
with a user's currently assigned IP address. As with ULS, the act of logging in to a 
dynamic DNS system causes a new DNS record to be created associating the user's static 
20 domain name with the user's cunent IP address. The DNS record is deleted v^ien the 

computer logs out or fails to continue to refresh its record. In this way, a user desiring to 
communicate with another user logged in to a dynamic DNS system can perform a 
standard DNS lookup on that user's static domain name to ascertain the user's current IP 
address. 

25 By 'replacing the non-standard name resolution techniques of ULS with 

standard DNS namii^ dynamic DNS solved some of the problems inherent in ULS. 
However, there are still disadvantages to using dynamic DNS as a means of locating and 
communicating with an intermittendy connected user, Fu^t, dynamic DNS only provides 
a user's current IP address. It does not provide complete dynamic session information for 

30 a user, including such information as a user's host box identifier, TCP port number on 
which to be reached, and session ID. Knowledge of a user's complete dynamic session 

-3- 
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information facilitates the use of multiple possible fonns of conununication (e.g., type 
chat, voice, video, etc). 

Second, knowledge of a user*s dynamic IP address through dynamic DNS 
only allows for limited forms of commuiucation. For example, a user can take an IP 
address and communicate using an H323 protocol communications sq>plication such as 
Microsoft NetMeeting. A user could not, however, type the IP address into a web 
browser and communicate using the HTTP protocol. The inability to allow HTTP 
communications is particularly disadvantageous in that HTTP contununications can take 
place even with users located behind firewalls and proxy servers - security measures that 
are growing more and more prevalent today. By contrast, H323 communications will not 
easily function through a firewall, unless plication modifications are made. 

Existing type chat / instant messaging applications are also 
disadvantageous in that they do not operate using the HTTP protocol. These implications 
typically require the download of large software programs that operate using proprietaiy 
formats that are incompatible with one another, precluding the interoperability of the 
various applications. Moreover, Ae applications do not transmit messages using the 
HTTP protocol. Indeed, some do not even send messages using Transmission Control 
Protocol/Internet Protocol (TCP/IP), the transport protocol underlying the HTTP i^otocol 
and most other Internet transmissions, but Instead use User Datagram Protocol (UDP). 
These type chat / instant messaging applications therefore do not function behind most 
firewalls and proxy servers, 

Thm is thus a need for a communications system that vnli allow the 
association of a static name with a user*s complete dynanuc session information. There 
is also a need for a communications system that will facilitate multiple forms of 
communication with a user given knowledge of only the user's static name. There is also 
a need for a communications system that will fecilitate multiple forms of communication 
using the HTTP protocol, and thus will allow communication with users and devices 
located behind firewalls and proxy servers. 
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SUMMARY OF THE INVENTION 

Briefly stated, the present invention provides a computer-implemented 
method of facilitating communication with an entity over a network. In the method, a 
static HyperText Transfer Protocol (HTTP) Universal Resource Locator (URL) is 
associated with the entity. The URL is linked with communications information 
reflecting the entity's current online presence including the entity's dynamic session 
information as determined using the HTTP protocol. Communication with the entity is 
facilitated using the URL and the conununications information. 

In another embodiment, the present invention provides a computer- 
implemented method of facilitating conununication over a network with one or more 
members of a group of entities, the groiq> comprising a pluraliQr of entities. In the 
method, a static HTTP URL is associated with the group of entities. The URL is linked 
with conununications information reflecting each of the members* current online 
presence including each of die members* dynamic session information as determined 
using the HTTP protocol. Communication with one or more members of the group is 
facilitated using the URL and the conunimications information. 

In yet another embodiment, the present invention provides a computer- 
implemented method of determining the cunent online presence of an entity on a 
computer network. In the method, a static HTTP URL is associated with the entity. The 
URL is linked with communications information reflecting the entity's currrat online 
presence including the entity's dynamic session information as determined using the 
HTTP protocol. Tte current online presence of the entity is determined using the URL 
and the communications information. 

In yet another embodiment, the present invention provides a computer- 
implemented method for detecting and maintaining an entity's cunent online presence on 
a computer network, the network including a host computer. In the method, an HTTP 
request is sent firom the entity to the host computer to initiate an HTTP coimection 
between the entity and the host computer. Next, the request is received at the host 
computer and a socket is opened and maintained for the HTTP coimection with the entity 
in a non-blocking maimer without a new thread being created for the HTTP coimection. 
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Finally, at least one byte of data is sent from the host computer to the socket at a 
specified interval to keep open the HTTP connection with the entity. 

In yet another embodiment, the present invention provides a computer- 
implemented method for detecting and maintaining the current online presmce on a 
computer network of a plurality of entities, the network including a host computer. In the 
method, a reque^ is received at the host computer from one of the plurality of entities to 
establish an HTTP connection. Next, a socket is opened and maintained for the HTTP 
connection in a non-blocking manner, the socket having a socket file descriptor, with the 
one of the plurality of entities without a new thread being created for the HTTP 
connection. Next, the socket file descriptor is added to a socket database, the socket 
database mai nt a i ning a list of open sockets with those of the plurality of entities that are 
currenUy onlme. Finally, at least one byte of data is sent fiom the host computer to the 
open sockets in the socket database at a q)ecified interval to keep open the HTTP 
connections with the plurality of entities. 

In yet another embodiment, the present invention provides a computer- 
implemented method of sending text messages firom a fiirst entity to a second entity over a 
network using HTTP, the network including a host computer. In the method, a socket 
and an HTTP connection between the second entity and the host computer is established 
and maintained. Next, a text messs^e is sent ftom the first entity to the host comimter to 
be delivered to the second entity. Finally, the text message is sent to the second entity 
fi-om the host computer using the socket and the HTTP connectioiL 

In yet another embodiment, the present invmtion provides a computer- 
implemented method of UanqMrting Session Initiation Protocol (SIP) messages from a 
fij:st entity to a second entity over a network, the network including a host CO In 
the method, a socket and an HTTP connection between the second entity and the host 
compum is established and maintained. Next, a SIP message is sent fnnn the first entity 
to the host computer to be delivered to the second entity. Finally, the SIP message is sent 
to tl^ second entity fiom the host conq[>uter using the socket 

Finally, in yet another embodiment, the present invention provides a 
computer*implemented method of srading text messages fit>m an entity to an Internet 
enabled wireless device over a network, the network including a host computer. In the 
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method, a communications request is sent to the Internet enabled wireless device from the 
host computer that includes an URL identifying the host computer. A socket and an 
HTTP connection between the Internet enabled wireless device and the host computer is 
established and maintained using the URL. Next, a text message is sent from the entity to 
the host computer to be delivered to the Internet enabled wireless device. Finally, the 
text message is sent to the Internet enabled wireless device from the host computer using 
the socket ^d the HTTP connection. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing summary, as well as the following detailed description of 
preferred embodimrats of the invention, will be better understood when read in 
conjunction with the appended drawings. For the purpose of illustrating the invention, 
there are shown in the drawings embodunents that are presently preferred. It should be * 
understood, however, that the invention is not limited to the precise arrangements and 
instrumentalities shown. In the drawings: 

Fig. 1 is a high-level architecture block diagram configuration for one 
preferred embodiment of the present invention; 

Fig. 2 is a fimctional flowchart of the steps to establish the online presence 
of an entity in a preferred embodiment of the present invention; 

Fig. 3 is a block diagram showing the functioning of a socket handler in a 
preferred embodiment of the present invention; 

Fig. 4 is a functional flowchart of the steps to tpaintain the online presence 
of an entity in a preferred embodiment of the present invention; 

Fig. 5 is a functional flowchart of die steps to login an enti^ into the 
presence propagation system in a preferred embodiment of the present invention; 

Fig. 6 is a functional flowchart of the steps to logout an entity from the 
presence propagation system in a preferred embodiment of the present invention; 

Fig. 7 is a functional flowchart of the steps to join an entity to a group in 
the presence propagation system in a preferred embodiment of the present invention; 
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Fig. 8 is a functional flowchart of the steps to remove an entity from a 
group in the presence propagation system in a preferred embodiment of the present 
invention; 

Fig. 9 is a portion of a UserTable in a preferred embodiment of the present 

invention; 

Fig. 10 is a portion of a UserTable in a preferred embodiment of the 
in«sent invention; 

Fig. 1 Us a sample communications web page displayed to a registered 
user of a prefored embodiment of die present invention; 

Fig. 12 is a functional flowchart of the stq>s to update a communications 
web page displayed to a registered user of a preferred embodiment of the present 
invention; 

Fig. 13 is a sample communications web page displayed to a registered 
user of a preferred embodiment of Ac i»esent invention; 

Fig. 14A is a functional flowchart of the steps to display a 
communications web page to a requesting entity using a preferred embodiment of the 
present invention; 

Fig. 14B is a functional flowchart of the steps to redirect an URL using a 
preferred embodiment of the present invention; 

Fig. 1 5 is a sample communications web page displayed to a requesting 
entity using a preferred embodiment of the present invention; 

Fig. 16 is a sample communications web page displayed to a requesting 
entity using a preferred embodiment of the presort invention; 

Fig. 17 is a functional flowchart of the steps to tranqxirt type chat/instant 
messages using a preforred embodiment of the pteseat invention; 

Fig. 1 8 is a functional flowchart of the steps to tranqwrt a SIP message 
using a preferred embodiment of die |»esent inveirtioiu 

Fig. 19 is a sample communications web page di^layed to a registered 
user of a preferred embodiment of the present invention; and 
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Fig. 20 is a functional flo^vchart of the steps to transport two-way text 
messages to an Internet enabled wireless device using a preferred onbodiment of the 
present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

S Certain terminology is used herein for convenience only and is not to be 

taken as a limitation on the present invention. In the drawings, the same reference 
numerals are employed for designating the same elements throughout the several figures. 

The i^esent invention is described in the contesa of a communications 
system used to facilitate communication with mtities over a computer netwoiic such as 

10 the Internet or an Intranet Thetarm''entity**isusedheremtomeanany type of device 
with any type of an IP connection (e.g., wired, wireless, etc.) to a network. For example, 
an entity could be an Internet enabled personal computer (PC), l^top, workstation or 
oiher type of computer. An entity could also be an Intemet enabled wireless telephone, 
personal digital assistant (PDA) such as a Palm Pilot, or even an appliance or otiier 

1 5 household device. 

Turning to Fig. 1, a high-level architecture block diagram configuration 
for one preferred embodimmt of the conmiumcations system of the present invention is 
shown. A backend SCTver 10 is networked to one or more session manager servers 12. 
The session manager servers 12, in turn, are preferably networiced to a load balancer 14, 

20 which is preferably connected to a public network, such as tiie Internet, through a fiiewall 
16. One or more client devices 1 8 (i.e., entities) are also connected to the Internet 
Additionally, the backend server 10 may be networked to a gateway 20, which can 
communicate with a telephone 22 using a telephony network (not shown). 

The backend server 10 contains two databases and, as will be discussed in 

25 detail below, nms the presence propagation (PP) system. The first database 24 is used to 
store persistent information for tiie conomunications system. For example, the first 
database 24 stores the names and mailing addresses of users of the conununications 
system, the users' usemames and passwords for authentication/vaification, the list of 
groups to vdiich users belong (to be explained below), and possibly other user 

30 demogrsqphic data. The first database 24 also stores information on tiie groups that have 
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been defined in the communications system, including a list of the groups that have been 
defined, passwords for those groups that require them, and a list of the members of each 
group. The first database 24 can be implemented using any database application, such as 
Oracle or SQL-based databases. Access to the first database 24 can also be managed 
S through any means. For example, in a Java environment, access can be handled using a 
Java database connectivity (JDBC) interface. 

The second database 26 is used to store non-persistent information for the 
communications system. The second database 26 primarily consists of two data tables. 
The first data table contains the dynamic session information (to be explained below) for 

iO all users that are currently online. The second data table contains a list of all of the 

groups that currratly have members online, and, for each such group, a list of all of the 
members that are currently online. Since the information in the second database 26 
changes often and the information is accessed frequently, the second database 26 is 
preferably stored as hash tables m fhe memory of the backend server 10. The second 

1 5 database 26 could be implemented using any database application. The first database 24 
and the second database 26 may be combined into a single database, if desired. 

The session manager servers 1 2 interact with die client devices 1 8 over the 
network (e.g.. Intranet or Internet). The session manager server 12 includes a web server 
28, a chat server 30 and a socket handler 32. The session manager servers 1 2 preferably 

20 communicate with the backend server 10 using an inter-process communications protocol 

such as Remote Method Invocation (RMI). CORB A could also be used, as could any 
other communications protocol. 

The web server 28 is used to serve web pa^es and their components to a 
web browser or other af^Iication on a client device 1 8. The web server 28 can be 

25 implemented in any programming language, but is preferably implemented as a Java Web 
Server (JWS) using^ for example, Apache/Resin or WebLogic. 

The chat server 30 is used to maintain the online presence (i.e., heartbeat) 
of client devices 18 tiirough an HTTP connection betwem die clioit device 18 and the 
chat server 30. The chat servtf 30 is also used to send messages to and receive messages 

30 from the client device 18 through the HTTP connection. The diat saver 30 can be 
implemented in any i»ogramming language, but is preferably implemented as a Java 

-10- 
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seivlet. Moreover, although shown as a separate process from the web server 28, the chat 
server 30 and the web server 28 can be combined into a single application. 

The chat server 30 also includes a socket handler 32. As will be explained 
in detail below, the socket handler 32 is used to establish and maintain an HTTP 
5 connection between the chat server 30 and the cli«it device 1 8 without the need of 

creating a new thread Accordingly, the chat server 30 can maintain HTTP connections 
with many client devices 18 using very little overhead The socket handler 32 can be 
implemented in any programming language, but is preferably inqilCTiented using C-^, 
One or more session manager servers 12 can be used in the 

10 communications system ofthe present in vmtion. The number of session manager servers 
12 used will dep^ on the anticipated number of users of the system. The higher tfie 
level of anticipated users, the more session manager servers 12 that should be used. With 
server hardware such as a standard Unuc server, such as, for example, a Sun E4S0, it is 
anticipated that each session manager server 12 can support up to ^^proximately 10,000 

1 S simultaneous users. 

Any server hardware may be used for the backCTd server lOandthe 
session manager s&cvers 12. Pteferably, Unix servers are used. Moreover, although 
shown as separate servers in Fig. 1, the backend server 10 and the session manager 12 
could be combined into a single server. Of course, the web server 28 and the chat server 

20 30 could also be broken out into separate servers. 

The session manager servers 12 are preferably coimected to the Internet or 
other network using a load balancer 14 and a firewall 16. The load balancer 14 
distributes network traffic among the session manager servers 12 so that none of the 
session manager servers 12 become overburdened* Any conventional load balancer can 

25 be used for die load balancer 14, such as, for example, a Foundry Server lion. The 

firewall 16 provides security for the session numager servers 12 and the backend server 
1 0, preventing unauthorized access to the servers over the network. Any combination of 
firewall software and/or hardware can be used for the firewall 16, such as, for example. 
Check Point FiieWall. 

30 Hie gateway 20 is used to provide access to a telephony network. Using 

the gateway 20, voice data from the communications system of the present invention, 

-11- 
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such as VoIP, can be sent through a telephony network to a telephone 22. Thus, users of 
the communications system are able to initiate telephone calls fiom client devices 18. 
Any existing gateway technology may be used for the gateway 20, such as, for example, 
Cisco VoIP routers. 

Finally, the client devices 18 are the users of the communications ^stem. 
As noted above, the client devices 1 8 can be any entity - namely any type of device with 
any type of an IP connection (e.g., wired, wireless, etc.) to a network. For example, as 
shown in Fig. 1 , a client device can be a laptap compu^, a computor workstation, a PDA 
or an Internet enabled wireless jriione. The client devices 18 interact wiA ibc 
communications system over a networic, such as ttie Intonet 

The client devices 18 prefmbly access the communications system either 
through a web browser 34 or through a download application 40. First, tiie 
communications system can be accessed through any web browser 34, such as Internet 
Explorer or Netscape Navigator or a Wireless Marioq) Language (WML)/Handheld 
Device Markup Language (HDML) browser on an Internet enabled wireless device. As 
will be explained in detail below, the web browser 34 can display web pages 36 served 
fiom the web server 28. Additionally, an aiglet 38 running on a web page 36 
communicates with the chat server 30. The s^plet 38 is tied to a particular web page 36, 
and is preferably contained in a hidden frame in the web page 36. It is also possible to 
use any other functionality in place of the applet 38, such as, for example, an ActiveX 
control, to communicate with the chat server 30. 

Alternatively, a download application 40 can be installed on a client 
device 1 8 to allow the client device 1 8 to access tihe communications system. The 
download application 40 has two components. First, the implication 40 needs to be able 
to display wd» pages 42 served fiom die web server 28. This can be accompli^ed ei&cr 
by launchmg a web browser abeady resident on the client device 1 8 or by providing a 
new applicadon capable of interacting with the web server 28. The download ^iplication 
40 also contains a CX:HAT apphca&m 44 diat communicates with the chat server 30. 
The CCHAT application 44 is preferabfy written in C, aldiough can be written in any 
programming language, and serves die same fimction as die applet 38. Unlike die ^plet 
38, however, die CCHAT application 44 is not linked to a particular web page 42. 

-12- 
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Now that the overall architecture of a preferred embodiment of the 
communication system of the present invention has been described, the functionality of 
the communication system will be discussed. First, the process by which a user 
establishes and maintains online presence will be disctissed. 

Initially, a user must register with the communications system. In 
particular, the user must pick a usemame and password that will be used to allow the user 
to log into die system and thus maintain his presence on line. Additionally, the user's 
usemame will be used to allow others to communication with the user. For example, as 
discussed below, the HTTP URL httpy/pxcaU.comAisemame will aUow anyone, whether 
or not they are registered to use the communications system, to communicate with the 
user. 

Once a user has registered with the communications system, the user can 
exploit the system. Fig. 2 shows the steps taken by a client device 18 to establish and 
maintain online presence. First, the user logs on to the communication system. If the 
cUem device 1 8 is running a web browser 34. the user enters an HTTP URL, such as 
http://www.planetexchange.com, and then enters a usemame and password to log into the 
system. If the user's usemame and password are recognized as vahd, the session 
manager server 12 to which the user has been directed sends a web page 36 that includes 
the applet 38. The session manager server 12 also preferably sends a unique session ID, a 
large random number that the client device 18 will use in all communications with the 
session manager server 12. This security measure assures that messages sent to the 
session manager 1 2 actually come from the cUent device 1 8. After receiving the session 
ID, the applet 38 initiates an HTTP request - e.g.. 

http://hostboxid^chat?!me=usemame&id=sessionID...., where hostboxid is the IP address 
of the session manager server 12. me is the user's usemame. and id is the unique session 
ID for that current user session - and waits to receive the requested web page. The applet 
38 wiU continue to wait until the user logs out of the system or closes the web page 36 
and dius stops the execution of the applet 38. Additionally, as will be discussed below, if 
a message is sent to the user, it is delivered to the user as an HTTP response to this 
request By making an HTTP request, the applet 38 maintains a "virtual" continuous 
HTTP connection with flie session manager server 12. This HTTP connection is what 
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establishes and maintains the online presence of the user. As will be described in detail 
below, scalability and optimization using this HTTP-based approach for m^.mtoi«{»g 
presence is preferably achieved by maintaining the user connections without creating a 
new thread to maintain and access each socket connection in a non-blocking manner. 

It is also possible to maintain a user's presence (i.e., heartbeat) using 
HTTP in different manners. For example, multiple HTTP requests can be used to 
maintain presence by having the applet 38 make periodic HTTP requests to the session 
manager 12 to establish and maintain the online presmce of the user. 

AJtmiatively, the above process can be automated if the client device 18 is 
using the dovmload application 40. For example, the cUent device 18 can be set up so 
that the CCHAT application 44 executes when the client device 1 8 is turned on. The 
CCHAT application 44 can then automatically log the client device 1 8 into the system 
and dien initiato the HTTP request to open an HTTP connection once the CCHAT 
aiq)lication 44 receives tfie session ID fimn the session manager server 12. 

Fig. 3 shows how the session manager server 12 handles the HTTP request 
firom the client device 18. The HTTP request initiates a TCP/IP open socket request, 
which is received by the low-level socket jvocess 46, such as WinSock or Bericeley 
Sockets, on the session manager server 12. Normally, for the request to be handled in a 
non-blocking manner, it would proceed through an Application Program Interface (API) 
layer 48 before being sent to the application that will handle the open socket request, 
which in this case is the chat server 30. However, if an open socket request is handled in 
this manner, a new thread (e.g.. a lightweight process in Unix, since Unix does not 
natively allow for threads, just forked processes) is created and maintained for each open 
sodcet connection. Thete is system oveiliead associated with tbe seating and 
maintaining of tfiousands of threads. v/tuOi would create problons in scalalnlity, since 
evoy user logging into tiie communicati<ms syston would result in the creation of an 
additi(»ial thread. Creating and maintaining a new ttiead with each open socket request 
would limit the number of simultaneous users per typical session manager server 12 to 
aj^ximately 3000. 

To avoid the oveifaead associated with the creation of new threads, the 
communication system of the present invention uses the AltSock socket handler 32. The 
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AltSock socket handler 32 is a shim that handles the open socket request instead of the 
API 48. The low-level socket process 46 hands the open socket request to the AltSock 
socket handler 32. The AltSock socket handler 32 accesses the socket simply by 
referencing its file descriptor in the socket table in the memory of the chat server 30, 
rather than creating a new thread to maintain and access the socket. Thus, there only 
needs to be a single thread to access all of the sockets, and thus all of the users, handled 
by the chat server 30 in a non-blocking manner. Using the socket handler 32, a typical 
session manager server 12 can handle 10,000 simultaneous users. 

The chat server 30 maintains a table in memory of all of the users that are 
online that it is hosting. For each useraame, the table contains the socket file descriptor 
of the HTTP connection for that user, as well as a counter that is used to keep the HTTP 
connection open. The table also preferably contains the user's dynamic session 
information, which will be mplained below. When a user logs into the system and the 
socket handler 32 receives an open socket request, a new entry is added to the table in the 
memoiy of the chat server 30 reflecting the new user, including dynamic session 
infomiation, socket file descriptor, and a counter initialized to its start value. As vwll be 
discussed below, the usemame and dynamic session information is also passed to the 
presence propagation (PP) systan so that others will be able to determine whether or not 
the user is online, and, if so, will be able to communicate with the user. 

Fig. 4 shows how the chat server 30 maintains the HTTP connections with 
the online users and thus maintains the online presence of those users. Every polling 
interval, which is preferably every four seconds, the chat server 30 cycles through the list 
of online users. For each user, the chat server 30 first checks to see if the socket 
associated with the user is still open. If the socket is not open, the user has logged off 

and the chat server 30 can remove die user fiom its table and can notify the PP systrai 
that the user has logged off If the socket is still open, the user's keep-alive counter is 
decremented. When the counter reaches zero (i.e., the keep-alive interval has been 
reached, which is preferably 60 or 1 20 seconds), a byte is written to the socket to keep 
the socket open, thereby keq>ing open the HTTP connection with the user. If the write 
operation fails, then the socket is not open. The user has thus lo^ed off and the chat 
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server 30 can remove the user from its table and can notify the PP system that the user 
has logged off. 

There are thus three ways that a user can be logged out after having logged 
into the communications system. First, if the user intentionally logs off of the netwoik 
(e.g., by clicking on a logout link or closing a web browser 34 or CCHAT plication 
44), a message can be seat from the client device 1 8 to the chat server 30 to log the user 
out. If, however, a logout message is not sent to, or not received by, the chat s«ver 30, 
tfie user can still be logged out v/hen the chat server detemiines during a polling interval 
that the socket associated the user is no longer open or detemiines during a keep-alive 
interval that it cannot write to the socket associated with the user. 

In the aiwve-described process, the HTTP connection with a user serves as 
a heartbeat to let the chat server 30 know whether or not the user is still online. Since the 
heaiAcat is created and maintained using an HTTP connection, die heartbeat will 
function behind any proxy server or firewall that allows HTTP traffic. Most firewalls 
and iwoxy servers allow such traffic since there is relatively little danger to a network 
from HTTP transmissions. 

Of course, one could implement the HTTP based heartbeat and 
communications using processes other than the presently preferred method described 
above. For example, a first possible variation incorporates the current in^lementation 
without the AltSock socket handler 32. Such a system would still work bdiind a firewall 
or proxy. In this variant, the open socket requests are completely handled within the API 
layer 48, for example within the Java Virtual Machine in a Java implementation, and a 
new thread is created and maintained for every connection by a client device 1 8. This 
method has the undesirable consequence that a givm session manager 12 would have to 
maintain a thread for every connected client device 1 8. 

A second variation uses HTTP as the transport, but uses a different 
algoridun for heartbeat and coimectioiL In this variation, die user makes periodic HTTP 
connections to the session manager 12 (peihaps evoy S-10 seccmds), and the user's 
presence Is detennined by the absence of "httping" packets. After a user logs in, periodic 
"httpii^" packets are sent to die session manager 12, and a user's |»esence Is deemed 
online until tiie packets stop. For example, this system could be implemented by starting 
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a timer when a user logs in. If the timer reaches zero, the user is logged out Otherwise 
if a keep-alive/httping packet is received, the timer is reset. This system will work 
behind a firewall or proxy. However, it is disadvantageous in that there is no way for the 
session manager 12 to send messages to the user until the user reconnects to the session 
manager server 12 and provides the connection pipe to communicate. Thus any updates, 
chats or other messages will be delayed until the next connection cycle. When the user 
reconnects at the next heartbeat interval, they will receive the messages. More 
importantly, this system will not scale well at all, as by design it floods itself with TCP 
connections under large loads. 

A third variation uses HTTP to transport some messages, but uses one or 
more additional TCP connections for additional signaling. In this type of a system, 
various messages are sent over HTTP transport, and any of the previously mentioned 
socket handling algorithms or heartbeat mechanisms can be implemented. However, one 
or more additional TCP cormections (such as, for example using Telnet, SSH, or an 
unassigned TCP Port) is made to the session manager 12, in order to establish 
authentication, or even to provide heartbeat and message passing. This hybrid HTTP 
system will not work behind a firewall or proxy without special configurations that 
compromise the security of the firewall or proxy. 

As discussed above, the PP system is notified "when a user logs into or out 
of the conununication system. This is important since the PP system rurming on the 
backend server 10 plays a c&atnd role in the ability of the communications system to 
allow others to communicate with users of the communications system. The PP system 
will now be described. 

As mentioned above, the second database 26 in the backend server 10 
maintains two data tables. The first data table CUserTable") maititamg a list of the 
dynamic session information for each user that is currently online. This dynamic session 
information includes: 

User IP - the IP address of the entity (i.e., client device 18) firom which 

the user is logged into the communications system. 
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Host Box Identifier - the IP address of the session manager server 12 diat 
is hosting the user (i.e., the session manager 12 that is maintaining the 
socket and HTTP connection with the user's client device 18). 
Port Number - the TCP port number on the client device 1 8 thiough 
which the HTTP connection is maintained (typically pott 80). 

The dynamic session information also preferably includes: 
Session ID - the unique session ID assigned to the user by the chat server 
30. 

Group Info - the list of groups to which the user belongs. 

Active Group - the group that the user currently has displayed on the 

client device 18. 

The second data table ("GroupTable") maintains a list of the groups that 
currently have members online together with a list of the members in each group that are 
currently online. A group is simply a group of users that has been given a defined name 
in the communications system and which a user is capable of joinmg. For example, 
eveiy user has a personal address book - namely, the user's group of contacts that the 
user wishes to track the online presence of and communicate with. Additionally, groups 
can be companies, divisions, clubs, etc. Password protection may be set up in the 
communications system to prevmt unauthorized users fiom joining groiqis or, as 
discussed below, displaying the communications page associated with the group. 

Fig. S shows how the UserTable and GroiqiTable are tqxlated by the PP 
system when a user logs onto the communication system. First, the chat server 30 that is 
hosting the user sends a login message to the PP system along with the User IP, Host Box 
Identifier, Port Number, and Session ID. The PP system adds the user to the UserTable 
along widi the (fynamic sessicm infonnation provided by the chat server 30. The PP 

syston then quoies the first database 24 to get the list of die gioiqs to the user 
belongs as well as the de&ult active group of the user. This additional information is 
added to the UserTable. Finally, the GroupTable is updated. For each group to which 
the user belongs, the user is added to the list for that group in the GroupTable. If a group 
to which the user belongs is not currently in the GroupTable, that group is added to the 
GroupTable with the user listed as the only online member. 
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Fig. 6 shows how the UserTabIc and GroupTable are updated when a user 
logs off of the communication system. As previously discussed, the chat server 30 
notifies the PP system when a user logs off. Figs. 7 and 8 show how the UserTable and 
GroupTable are updated when a user joins a gmvap and when a user leaves a group, 
respectively. The chat server 30 notifies the backend server 10 about the change in group 
membership. The first database 24 and fbs data tables of the second database 26 are 
updated. Since the procedures of Figs. 6-8 are very similar to those discussed above for 
Fig. S, they are not described in detail here. 

Thus, the PP system allows the communicati<Mi ^stem to track the current 
online presence of users including the dynamic session mfoimation for all online users. 
The PP system also tracks which groups cunently have membeis online and which 
members in those groups are currently online. For example. Fig. 9 shows a portion of a 
UserTable at 10:00 a.m. reflecting three users logged in to the system. User 1 has a set of 
current dynamic information stored in the UserTable. Similarly, user2 and user3 have 
their cuirait <fynamic session information stored in the UserTable. Fig. 10 i^resents the 
same UserTable at 3:00 pjn. As seen in the table, userl has logged out of the system and 
has subsequently logged back into the system between 10:00 a.m. and 3:00 p.m using a 
different client device 18. Accordingly, the dynamic session information for userl in the 
UserTable has changed. User2 has been continuously logged in to the system ftom the 
same client device 18, so the dynamic session information in the UserTable for user2 is 
the same in Figs. 9 and 10. User3 has logged off of the Internet and has not logged back 
in. Accordingly, user3 has no current dynamic session information in the UserTable. 
Finally, user4 has logged in to the system between 10:00 a.m. and 3:00 p.m., and thus has 
dynanuc sessi<m information in the UserTable in Fig. 10. 

Next, the use of the online presence information, and particularly the 
dynamic session information, maintained by the PP system in fecilitating communication 
witfi users of the communications system will be described. 

First, when a user logs into the communications system, a web jpage 36 or 
40 is preferably displayed apart fix>m the applet 38 or CCHAT api>Iication 44 that 
establishes and maintains the presence of the user using an HTTP connection. Fig. 1 1 
shows a sample communications web page SO that would be displayed to userl after 
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logging into the system. The web page 50 displays the members of userl 's active group 
(in this case, userl 's address book) and presents commtmications options to userl based 
on the online presence of the members of userl 's address book. Preferably, four 
communications options are presented: chat, PC to PC conununication, PC to Phone 
S communication, and the ability to leave a message for a user. Of course, a subset of these 
communications options could be presented, or other communications options could be 
displayed. Moreover, the web page 50 could also take any fomi so long as it presents a 
means (in the form of hypeilinks, images, etc.) to initiate communications options with 
the user. 

10 Chat is a real-time type chat or instant message capability. It can only be 

used with a user that is currently online* Thus, inFig. 11, where userl and user4 are 
online, a box ^spears indicating that userl can chat with those users. Further, since user2 
and user3 are offline, a line appears on the web page SO radier than a box, indicating that 
the chat communication format is not available with those users. Clicking on a box on 

IS the web page 40 will initiate die chosen commimications option with the indicated user. 

For example, clicking on box 52 will start a chat session with user4. Type chat / instant 
messaging using the communications system of the current invention will be explained in 
detail below. 

PC to PC communication is real-time voice and/or video conferencing. In 
20 order to use this commimications option, a client device 1 8 must be equipped with a 
sound card and microphone for voice communication and a video camera for video 
communication. This option is also only available with users that are currently online 
(e.g., userl and user4 in Fig. 1 1). When a user clicks to start a PC to PC call» the 
communications system launches an appropriate client iq;iplication on the client device 
25 such as Microsoft NetMeeting or another Internet based conomunications client such as 
an H323 client or a T120 client The communications system uses the dynamic session 
information stored in the UserTable - namely. User IP and possibly Port Number - to put 
the correct addressing information into the client plication to permit the PC to PC call 
to be connected* 

30 PC to Phone communication is real«time VoIP communication using the 

gateway 20 to connect voice conunimication between a client device 18 and a teIq>hone 
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22 at a telephone number stored in the first database 24. If a user has selected a 
telephone number where PC to Phone calls should be directed (which is stored in the first 
database 24), a box will appear in the web p^e 50, allowing PC to Phone communication 
to be selected for that user. For example, in Fig. 1 1, userl, user3 and user4 have stored 
5 phone numbers v^ere they can be reached A user does not have to be online for a PC to 
Phone call to be initiated. Thus, in Fig. 1 1, a box appears for PC to Phone 
communication with user3, even though userB is not currently online. When a user clicks 
to initiate a PC to Phone call, the communications system launches an appropriate client 
application on the client device 18 such as, for example, Microsoft NetMeeting. The 

1 0 telephone number stored for the user is retrieved fix)m die first database 24 and the call is 
routed to the telephony netwoik using the gateway 20. 

Finally, Ae message box, which is available for all users whether or not 
they are cunnently online, allows a user to leave a text or voiceMdeo message for the 
indicated user. The message, after being recorded or typed by the user, will be stored for 

15 the recipient in the first database 24. The recipient can then retrieve the mess^e and 
play it back by clicking on the messages link on the recipient's communications web 
page 50. 

Fig. 12 shows how a commxmications web p^e 50 is updated when a user 
logs on, logs off, joins a group or leaves a group. The updates are processed and 

20 displayed immediately, giving users of the communications system of the present 

invention a real-time indication of the online presence of the members of the active group 
displayed on their conununications web pages 50. First, as described above with respect 
to Figs. 5-8, the UserTable and GroupTable are updated as a result of a user logging in, 
logging out»joining a group or leaving a groiq>« Next, the PP system creates an iq>dato 

25 list of the online member(s) to be notified sorted by session manager server 12 (i.e*, host 
box). To avoid sending unneoessacy update information, die PP system checks ibe 
Active Group for each member to make sure that the update applies to this group. For 
example, looking at Fig. 1 1 , if usct2 came online and userl *s Active Group is the 
Address Book (as shown in Fig. 1 1), the iqxiate should go to userl . If, however, userl 's 

30 displayed Active Group was different and if that Active Group did not include user2, then 
userl should not receive an update that user2 came online. 
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Once the update list for each session manager server 12 is cieated, the lists 
are sent to the appropriate session manager server 12. Each session manager server 12 
receives the update lists for the member(s) it is hosting and places update messages in an 
update queue for each member that is stored in the chat server 30. The chat server 30 
then sends an HTTP encoded update message to the ^plet 38 or CCHAT application 44 
of each member that has an update message stored in its i^Klate queue. If the update list 
was created from a user joining or leaving a group, a refresh update messi^e is sent to the 
applets 38 or CCHAT applications 44 instead of an update mess^e. For example, 
looking again at Fig. 1 1 , if user2 comes online and user4 goes offline, the update list sent 
to the session manager server 12 hosting userl would include an update message for 
userl that user2 came online and usei4 went ofiOine. An update message would then be 
sent to the applet 38 or CCHAT application 44 of the client device 1 8 for userl . 

The update messages are sent fi-om the chat server 30 to the applet 38 or 
CCHAT q^lication 44 using the same socket and HTTP connection that have been 
established to maintain the online presence of the member and» as will be explained 
below, to send o&er types of messages such as text messages or SIP messages* The 
update messages can be of any format, but are preferably of the form "msg update 
updatetype," where updatetype represents the type of update to be perforaied (e*g., update 
single user presence, update User IP address, lefi^h page, etc,) 

When an applet 38 or CCHAT application 44 receives a refresh update 
message, the applet 38 or CCHAT application 44 causes the web page 36 or web page 40, 
respectively, to refresh. When the web server 28 sends the updated web page 36 or 40, it 
will include a new line for the user that was added to the displayed active group of the 
member if a user joined the group. If a user left the groiqp, the updated web page 36 or 40 
will have deleted the line for the user that was removed tnsm the displayed active group 
of the member. 

If» howevn, the applet 38 or CCHAT plication 44 receives an update 
message, it is unnecessary to refresh the entire web page, since the users displayed on the 
communications web page SO have not chaqged. Only the online status of the users has 
changed, and thus only the boxes displayed on the communications web page SO need to 
bechanged. Accordingly, iq)on receiving an update niess^e, die applet 38 or CCHAT 
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application 44 calls update.jsp. a hidden frame on the member's commtmications web 
page 50. In response, the web server 28 for the member gets the update messages in the 
update queue for the member from the chat server 30 and dynamically generates a web 
page containing JavaScript designed to change the images and links associated with the 
5 users that have logged in and out on the member's communications web page 50. 

For example, looking again at Fig. 1 1, in order to process the update 
messages for userl that user2 has come online and user4 has gone offline, the web server 
would generate JavaScript such as: 

runUpdateO 
10 { 

change image for chat-user 2 
change link for diat-user 2 
change image for call-user 2 
change link for call-user 2 
1 ^ change image for chat-user 4 

change Imk for chat-user 4 
change image for call-user 4 
change link for call-user 4 

> 

^® page generated by the web server 28 is then sent to the member, 

and the JavaScript runs on-load, which executes the dynamic scripts and updates the links 
and images on the communications web page 50. For example, if the above JavaScript 
was sent to the communications web page 50 as shown in Fig. U , the communications 
web page 50 would be changed as shown in Fig. 1 3. User2 is now shown as being 

25 online, and the chat and PC to PC options have been activated, while user4 is now shown 
as being offline and the chat and PC to PC options have been deactivated. 

The advantage of performing updates in tiiis manner is that the caitiie 
communications web page 50 does not need to be refreshed every time a user comes 
online or ofOine. This is particulariy advantageous when a user has an Active Group 

30 displayed tiiat has many members. Of course, a Java applet within the communications 
web page 50 could also be used to perform updates in this manner, without the use of 
JavaScript 

Fig. 19 shows a sample communications web page 50 that would be 
displayed to userl after logging in to the system in another preferred embodiment of the 
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communication system of the present invention. The web page 50 is identical to that 
shown in Fig. 1 1, except a fifth communication option is presented - PC to wireless 
device. 

PC to wireless device communications is two-way text messaging between 
a client device 1 8 and an Internet enabled wireless device. If a user has selected an 
Internet-enabled wireless device where PC to wireless device communications should be 
directed (which is stored in the first database 24), a box will appear in the web page 50, 
allowing PC to wireless device conomunication to be selected for that user. For example, 
in Fig. 1 1, user!, usa2 and user4 have stored wireless devices where th^ can be 
reached. A user does not have to be online for a PC to wireless device communication to 
be initiated. Thus, in Fig. 19, a box appears for PC to wireless device communication 
with user2, even though usei2 is not currently online. As with the other communications 
options described above, clicking on a box on die web page 50 will initiate the diosen 
communications option with the mdicated user. For example, clicking on box 52 will 
start a PC to viireless device communication with user4. PC to wireless device 
communication using the communications system of the current invention will be 
explained in detail below. 

The communications system of the present invention also allows 
requestors that are not registered users of the communications system of the present 
invention to communicate with users of the system. Every registered user and group gets 
at least one unique static HTTP URL which is linked with the dynamic session 
information stored in the second database 26 of tfie backoid server 10. The HTTP URL 
can thus be used to determine the current online presence of the user associated with the 
URL as well as facilitate communication with the tisa associated with the HTTP URL. 

The HTTP URL can take any fonn so long as it uniquely identifies the 
userorgroiQ). For example: 

http:/^call.coniAiseniame 

httprZ/pxcalLcom/groi^mame, 

htq>://pxcall.com/SecottdaryNameAisemame, 

ht4>://PrimaryName.pxcaU.com/SecotidaiyName/useniame 
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would all be valid URLs. Additionally, it is possible to have aliases defined, such that 
multiple HTTP URLs would all be associated with the same user and all perform in the 
same manner. For example, http://pxcall.com/UserName, 

http://pxcall.com/UserPhoneNumber and http*7/pxcall.com/UserEmailAddress could all 
be associated with the same user and all perform the same when used to determine the 
current online presence of the user or facilitate communication with the user. 

Preferably, the URL is typed into a web browser by the requestor in order 
for the requestor to determine the current online presence of the user associated with the 
URL or facilitate communication with the user associated with the URL. Of course, the 
URL can also be used in different manners to achieve the same conmumication 
objectives. For example, the URL's can be stored in a user's Favorite List or as 
Bookmarks. Additionally, the URL's can be placed as hyperlinks on web pages or 
associated widi images or other graphics on web pages and thus can be accessed by 
clicking on the hyperlink, image or other graphic. 

Figs. 14A and 14B show how a requestor uses the HTTP URL. First, the 
requestor enters the URL into a web browser on a client device 18 connected to the 
Internet or other network, or clicks on or otherwise activates a hyperlink associated with 
the URL. A redirector (not shown) parses the URL and redirects the client to one of the 
session manager servers 12 in an appropriate format. For example, 
http*7/pxcail.com/usemame may be translated into 

http://planetexchange.com/call2.jsp?name=usemame. The redirector provides standard 
URL redirection and may be located on any server, such as, for example, the backend 
server 1 0, the session manager server 1 2 or some odier independent server. 

As shown in Fig. 1 4B, the original URL is passed to the redirector, which 
translates the URL. The redirector dien sends an HTTP 301 Refuse (redirect URL) to 
the client along with the translated URL. The client then is directed to the session 
manager server 12. The web server 28 next queries the first database 24 to see if the user 
or group sought by the requestor requires password access to its communications web 
page. Ifso, the requestor is prompted to enter a password. Ifan incorrect password is 
supplied, the requestor is denied access to the communications web page. Otherwise, the 
web server 28 queries the second database 26 to determine the online presence of the user 
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or the members of the requested group. The web server 28 then presents a 
communications web page 50 to the client, showing the online presence information and 
presenting communications options to the requestor to facilitate communication with the 
user or members of the group. 

If the requestor entered the URL of an individual user, a communications 
web page 50 such as shown in Fig. 1 5 will be presented. The web page 50, including the 
functionality of the links on the page is analogous to that discussed above with respect to 
Fig. 1 1 . Alternatively, as shown in Fig, 14, if the user is not cuirratly online, the 
requestor may be presented with a web page 50 that only allows the requestor to leave a 
message for the user. For example, such a web page may have a text message or 
prerecorded voice/video message from the user requesting that a message be left on the 
page, the web page also presenting links to leave text or voiceMdeo messages. 

If the requestor entered the URL of a group, a commtmications web page 
50 such as shown in Fig. 16 will be presented. The web p^e 50, includix^ tiie 
functionality of the links on the page is analogous to that discussed above with respect to 
Fig.lL 

As shown in Fig. 14, after presenting the web page 50 on the requestor's 
browser, the web server starts a communication applet Aat is analogous to the ^plet 38 
discussed in detail above. This applet opens a socket and HTTP connection between the 
web server and the requestor's web browser that is analogous to the heartbeat mamtained 
with registered users of the communications system. This socket and HTTP connection 
are used to facilitate communication with the requestor, particularly for type chat/instant 
messaging. 

As discussed above, one of the forms of conununication facilitated by the 
communications system of the present invention is type chat /instant messagiiig. This 
communication option is presented to registered users on tiieir communications web 
pages 50 as shown in Fig. 11 and is also ineseitted to requestors on their communications 
web pages 50 as shown in Figs. 15 and 16. Fig. 17 shows how type chat/instant 
messaging preferably is canied out using the communications system of the present 
invention. First, the requestor cUcks on a link to initiate a chat with a registered user that 
is currently online. This action causes an HTTP request to be sent to the session manager 
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server 12 hosting the user. This request is of the form: ht^://hostboxipAinitohat?ine». 
to=. . . id=. . ., where me is the requestor, to is the recipient and id is the session id of the 
requestor. The chat server 30 on the session manager server 12 hosting the user writes an 
initChat message to be sent the ^plet 38 or CCHAT application 44 on the client device 
18 of the user. This message is preferably of the form "msg initChat" although it can be 
of any form. Similarly, the chat server 30 on tiie session manager server 12 hosting the 
requestor writes an initChat message to be sent the applet 38 or CCHAT appUcation 44 
on the client device 1 8 of the user. If flie requestor is not a registered user, then the 
message will be seat to the applet 38 associated with the requestor's web browser. The 
initChat messages cause the applet 38 or CCHAT application 44 to open a chat window 
or box on the client device 1 8 of the user and requestor. 

Chat messages are sent to.die chat server 30 on the session manager server 
12 of the receiving party using HTTP requests that are preferably of the form HTTP 
POST to /chat with elements me=. ses»onII>=. .... msg=text message, where me is the 
sender, sessionID is the session ID of the sender and msg is the text message to be sent 
These requests open a new socket for the transmission that is immediately closed after the 
post The chat messages are received by the chat server 30, where they are relayed to the 
receivii^ party by writing the bytes to the socket as part of the HTTP response that is the 
user connection between the chat server 30 and the ^plet 38 or CCHAT application 44. 
Upon receipt, the chat message is displayed in the chat window or box. 

Preferably, upon receipt of the message, the sodcet, and thus the HTTP 
connection between the receiving party and the chat server 30, is dosed. The receiving 
party ree^blishes its socket connection to the chat server 30 via another HTTP 
connection using the same process to establish a connection as e]q>lained above. Of 
course, the existing socket could be kept open, therein ranoving the need to reestablish 
the socket and HTTP connection. 

The Qrpe chat/instant messaging of the conununications system of the 
present invention is advantageous in that it is completely HTTP based. Accordingly, it 
will allow messages to be sent to any client device 1 8, whether or not it is behind a proxy 
server or firewall. Moreover, the type chat^nstant messaging does not require any 
proprietary download or proprietary fcmnat for the transmission of messages or the 
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detennination of the online presence information of the parties. The system is thus 
completely open and can be used by any client device 1 8 with a web browser connected 
to a network. 

As discussed above, another one of the forms of communication facilitated 
by the communications system of the present invention is two-way text messaging with 
Internet enabled wireless devices. This communication option is presented to registered 
users on their communications web pages 50 as shown in Fig. 19 and could also be 
presented to requestors on their communications web pages SO such as those shown in 
Figs. 15 and 16. Fig. 20 shows how text messaging with Internet enabled wireless 
devices preferably is earned out using the communications system of the present 
invention. First, the requestor clicks on a link to initiate two-way text messaging with a 
wireless device. This action causes an initChat message to be sent from the chat server 
30 hosting the requestor to the wireless device that includes an URL that identifies the 
chat server 30. This message is sent to the wireless device using a wireless telephony 
network. For example, the message can be sent to a Wireless Application Protocol 
(WAP) Gateway such as phone.com. Alternatively, the message can be sent to the 
wireless device using Short Message Service (SMS) messaging. 

The chat server 30 next checks to see if the message is successfully 
delivered to the wireless device. If not, the chat server 30 sends a message to the 
requestor that the wireless device is not available. If the message is delivered, the chat 
server 30 sends an initChat message to the applet 38 or CCHAT plication 44 on the 
client device 1 8 of the requestor. This mcssi^e is the same as desoibed above with 
respect to type chat in order to open a chat window or box on the client device 1 8 of the 
requestor. 

The user of the wireless device can then respond to the initChat inessage 
sent to the wireless device to initiate two-way messaging with the requestor. The 
wireless device responds by making an HTTP request to the URL sent in the initChat 
message. This request can be made, for example, using a WML/HDML browser on the 
wireless device. The request is used to establish and mait^t ^Tn a socket between the 
wireless device and the chat server 30 using the identical process as explained above with 
respect to other client devices 18. The socket is also maintained using the same method 

-28- 



wo 01/37139 



PCT/USOO/31601 



as described above. Messages can then be sent back and forth between the requestor and 
the wireless device using HTTP requests as described above with respect to type 
chat/instant messaging. The messages are displayed in the requestor's chat window or 
box, and are displayed on the wireless device using appropriate WML/HDML formatting. 
S The socket and HTTP connection established between a chat server 30 and 

the applet 38 or CCHAT application 44 on the client device 18 of a registered used can 
also be used to transport other types of information across proxy servers and firewalls 
that otherwise would not be able to cross such barriers. For example. Session Initiation 
Protocol (SIP) has generated a tremendous amount of recent interest. However, SIP 

1 0 messages cannot pass through a proxy server/firewall barrier, as they can be either UDP 
or TCP based. The conununications system of the present invention could be used to 
provide a means of transporting SIP messages across a proxy server/firewall. Fig. 18 
shows how the transportation of SDP messages preferably is carried out using the 
communications system of the present invention. The chat server 30, vsdiich is placed 

1 5 outside of a user's proxy server/firewall, can act as a SIP proxy for the user- As shown in 
Fig. 1 8, the chat server 30 receives a SIP request for the user. The chat server 30 then 
relays the request to the user using the socket and HTTP connection with the user as 
described above. For example, the chat server 30 preferably sends a message of the form 
"msg siprep reqtype", where reqtype is the type of SIP request received by the chat server 

20 30. When this message is received by the applet 38 or CCHAT application 44 on the 

client device 1 8 of the user, the applet 38 or CCHAT application 44 could then execute 
some form of SIP client application on the client device 18 to respond/process the SIP 
request. Of course, the SIP functionality could be built into the applet 38 or CCHAT 
application 44 rather than a separate application. In this way, SIP messages can be sent 

25 to users using HTTP connections and thus can pass across a proxy server/firewall. 

The present invention may be implemented with any ccmibination of 
hardware and software. If implemented as a computer-iii4>lemented apparatus, the 
present invention is implemented using means for performing all of the steps and 
functions described above. The present invention also can be included in an article of 

30 manufacture (e.g., one or more computer program products) having, for instance, 
computer useable media. The media has embodied therein, for instance, computer 
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readable program code means for providing and facilitating the mechanisms of the 
present invention. The article of manufecture can be included as part of a computer 
system or sold separately. 

It will be appreciated by those skilled in the art that changes could be 
made to the embodiments described above without departing fh)m the broad inventive 
concept thereof. It is understood, therefore, that this invention is not limited to the 
particular embodiments disclosed, but it is intended to cover modifications within the 
spirit and scope of the present invention. 

What is claimed is: 
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CLAIMS 

1 . A computer-implemented method of &cilitating communication with an entity over a 
network, the method comprising: 

(a) associating a static HTTP URL with the entity; 

(b) linking the URL with conummications information reflecting the entity's current 
online presence including the entity's dynamic session information as determined using the 
HTTP protocol; and 

(c) using the URL and the communications information to facilitate communication with 
the entity, 

2. The method of claim 1 wherein the dynamic session information includes the entity's 
current dynamic IP address and host box identifier. 

3. The method of claim 2 wherein die dynamic session information includes the entity^s 
TCP port number on vMch to be reached. 

4. The method of claim 2 wherein the dynamic session information includes the entity's 
session ID. 

5. The method of claim 1 wherein step (c) is performed by displaying a communications 
web page associated with the entity, the communications web page reflecting the entity's current 
online presence and including hyperlinks to facilitate commtmication witfi the entity based on the 
entity's dynamic session information. 

6. The method of claim 5 wherein the communications web page is displayed as a result 
of the HTTP URL being typed into a web browser. 

7. The method of claim 5 wherein the conummications web page is displayed as a result 
of clicking on or otherwise activating a hypwlink associated with the HTTP URL. 
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8. The method of claim 1 whetein multiple foms of communication with the entity are 
facilitated. 

9. The method of claim 8 wherein the forms of conununication include type chat/instant 
messaging, voice conununication over a computer network, video communication over a 
computer network, voice communication from a computer network to a telephone network and 
two-way text messaging to Internet enabled wireless devices. 

1 0. The method of claim 1 wherein the static HTTP URL contains entity-selected 
information. 



1 1 . The method of claim 1 further comprising: 

(d) associating additional, different static HTTP URLs with the entity; 

(e) linking the additional URLs with the same commimications information reflecting the 
entity's current online presence including die entity's dynamic session information as determined 
using the HTTP protocol; and 

(0 using the additional URLs and the communications information to facilitate 
communication with the entity. 

1 2. A computer-implemented method of £icilitating conununication over a network with 
one or more members of a group of entities, the ffmsp comprising a plurality of ratities, the 
method comprising: 

(a) associating a static HTTP URL widi the gn>tq>; 

(b) linking the URL with communications information reflecting each of the members* 
current online presence including each of the members' dynamic session information as 
determined using the HTTP protocol; and 

(c) using the URL and the communications information to fiicilitate communication vnUi 
one or more members of the group. 

13. The method of claim 12 wherein the dynamic session information includes each of 
the members' current dynamic IP address and host box identifier. 
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14. The method of claim 13 wherein the dynamic session infomiation includes each of 
the members' TCP port nimiber on which to be reached. 

15. The method of claim 13 wherein the dynamic session information includes each of 
the members' session ID. 

1 6. The method of claim 12 wherein step (c) is perfomed by displaying a 
communications web page associated with the group, the communications web page reflecting 
each of the members' current online presence and including hyperlinks to facilitate 
communication with each of the members based on tte members' dynamic session information. 

17. The method of claim 16 i^erein the communications web page is displayed as a 
result of the HTTP URL being typed into a web browser. 

18. The method of claim 16 wherein the communications web page is displayed as a 
result of clicking on or otherwise activating a hyperlink associated with the HTTP URL, 

1 9. The method of claim 1 2 wherein multiple forms of communication with each of the 
members of the group are facilitated. 

20. The method of claim 19 wherein the forms of communication include type 
chat/instant messaging, voice communication over a computer network, video communication 
over a computer network, voice communication from a computer network to a telephone network 
and two-way text messaging to Internet enabled wireless devices. 

21 . The method of claim 12 wherein the static HTTP URL contains group-selected 
information. 

22. The method of claim 12 further comprising: 

(d) associating additional, different static HTTP URLs with the group; 
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(e) linking the additional URLs with the same communications information reflecting 
each of the members' current online presence including each of the members^ dynamic session 
information as determined using the HTTP protocol; and 

(f) using the additional URLs and the conmiunications infonnation to facilitate 
conmiunication with one or more members of the group. 

23. A computer-implemented method of determining the current online presence of an 
entity on a computer network, the method comprising: 

(a) associating a static HTTP URL with the entity; 

(b) linking the URL with communications infomiation reflecting the entity's current 
online presence including the entity's dynamic session information as determined using the 
HTTP protocol; and 

(c) determining the current online presence of the entity using the URL and the 
conununicalions information. 

24. The mettuxl of claim 23 wherein flie dynamic session infonnation includes the 
entity's current dynamic IP address and host box identifier. 

25. The method of claim 24 wherein the dynamic session information includes the 
entity's TCP port number on which to be reached. 

26. The method of claim 24 wherein the dynamic session information includes the 
entity's session ID. 

27. The method of claim 23 wherein the static HTTP URL contains entity-sete^ 
infonnation. 

28. A computer-implemented mediod for detecting and maintaining an entity's current 
online presence on a computer netwoik, die network including a host computer, the method 
comprising: 
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(a) sending an HTTP request from the entity to the host computer to initiate an HTTP 
connection between the entity and the host computer; 

(b) receiving the request at the host computer and opening and maintaining a socket for 
the HTTP connection with the entity in a non-blocking manner without creating a new thread for 
the HTTP connection; and 

(c) sending at least one byte of data from the host computer to the socket at a q>ecified 
interval to keep open the HTTP connection with the entity. 

29. The method of claim 28 further comprising: 

(d) checking the online status of the entity by polling the socket at a second specified 
interval to determine if the socket is open and deciding that the entity is still online if the socket 
is open and that the entity has gone offline if the socket is no longer open. 

30. The method of claim 29 wherein the second specified interval is 4 seconds. 

3 1 . The method of claim 28 wherein the specified interval is one minute. 

32. The method of claim 28 wherein the specified interval is two minutes. 

33. The method of claim 28 wherein the HTTP request is a GET request 

34. The method of claim 28 fiirther comprising: 

(d) closing the socket at the host computer iQ>on receiving a message from the entity that 
it is logging off of the network. 

35. A computer-implemented method for detecting and maintaining the current online 
presence on a computer network of a plurality of entities, the network including a host computer, 
the method comprising: 

(a) receiving a request at the host computer fit>m one of the plurality of entities to 
establish an HTTP connection; 
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(b) opening and maintaining a socket for the HTTP connection in a non-blocking manner, 
the socket having a socket file descriptor, with the one of the plurality of entities without creating 
a new thread for the HTTP connection; 

(c) adding the socket file descriptor to a socket database, the socket database maintaining 
a list of open sockets with those of the plurality of entities that are currently online; and 

(d) sending at least one byte of data from the host computer to the open sockets in the 
socket database at a specified interval to keep open the HTTP connections with the plurality of 
entities. 

36. The method of claim 35 furtfa^ comprising: 

(e) checking the online status of the plurality of ratities by polling the open sockets in the 
socket database at a second ^cified intoval to determine if the open sockets are open and 
deciding that each of the plurality of entities is still online if its corresponding socket is open and 
that each of the plurality of entities has gone offline if its corresponding socket is no longer open. 

37. The method of claim 36 wherein the second specified interval is 4 seconds. 

38. The method of claim 35 wherein the specified interval is one minute. 

39. The method of claim 35 wherein the specified interval is two minutes. 

40. The method of claim 35 fiirtlier comprising: 

(e) closing a socket at the host computer upon receiving a message fiom a corresponding 
one of the plurality of entities that it is logging ofif of the network; and 

(f) removing die socket firom the socket database. 

41 . A computer-implemented method of sending text messages fix>m a first entity to a 
second entity over a networic using HTTP, the network including a host computer, die mediod 
comprising: 

(a) establishing and maintaining a socket and an HTTP connection between die second 
entity and the host computer; 
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(b) sending a text message from the first entity to the host computer to be deliveied to the 
second entity; 

(c) sending the text message to the second entity from the host computer using the socket 
and the HTTP connection. 

42. The method of claim 41 wherein step (b) is performed by: 

(i) establishing and maintaining a second socket and a second HTTP connection between 
the first entity and the host computer; and 

(ii) sending the text message from the first entity to the host computer using the second 
socket and the second HTTP connection. 

43. The method of claim 42 wherein a reply message is sent from the second entity to the 
first entity, the method fiirther comprising: 

(d) sending a reply message from the second entity to the host computer using the socket 
and the HTTP connection; and 

(e) sending the reply message from the host computer to the first entity using the second 
socket and the second HTTP connection. 

44. The method of claim 41 further comprising: 
(d) displaying the text messs^e on the second entity. 

45. A computer-implemented method of transporting SIP messages from a first entity to 
a second entity over a netwoik, the netwoik including a host computer, the method comprising: 

(a) establishing and maintaining a socket and an HTTP connection between the second 
entity and the host computen 

(b) sending a SIP message from the first entity to the host computer to be delivered to the 
second entity; 

(c) sending the SIP message to the second entity fix)m the host computer using the socket. 

46. The method of claim 45 fiuther comprising: 
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(d) sending a reply to the SIP message from the second entity to the host computer using 
an HTTP request. 

47. A computer-implemented method of sending text messages fix)m an entity to an 
Internet enabled wireless device over a network, the network including a host computer, the 
method comprising: 

(a) sending a communications request to the Internet enabled wireless device from the 
host computer that includes an URL identifying the host computer; 

(b) establishing and maintaining a socket and an HTTP connection between the Internet 
enabled wireless device and the host computer usii^ tfie URL; 

(c) sending a text message from the entity to the host computer to be delivered to the 
Internet enabled wireless device; 

(d) sending the text message to the Internet enabled wireless device from the host 
computer using the socket and the HTTP connection. 

48. The method of claim 47 wherein step (c) is performed by: 

(i) establishing and maintaining a second socket and a second HTTP coimection between 
the entity and the host computer; and 

(ii) sending the text message from the entity to the host computer tising the second socket 
and the second HTTP connection* 

49. The method of claim 48 wherein a reply message is sent from the Internet enabled 
wireless device to die entity, the method fiirther comi»ising: 

(e) sending a reply message from the Internet enabled wireless device to the host 
computer using the socket and die HTTP connection; and 

(f) sending the reply message from the host computer to die entity using the second 
socket and the second HTTP connection. 

50. The method of claim 47 further comprising: 

(d) displaying the text message on the Internet enabled wireless device. 
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5 1 . An article of manufacture for facilitating communication with an entity over a 
network, the article of manufacture comprising a computn^readable medium holding computer- 
executable instructions for performing a method comprising: 

(a) associating a static HTTP URL witii the entity; 

(b) linking the URL with communications information reflecting the entity's currmt 
online presence including the entity's dynamic session information as determined using the 
HTTP protocol; and 

(c) using the URL and the communications information to facilitate communication with 
the entity. 

52. The article of manufacture of claim 5 1 vlierein the dynamic session information 
includes the entity's current dynamic IP address and host box identifier. 

53. The article of manufacture of claim 52 wherein the dynamic session information 
includes the entity's TCP port number on which to be reached. 

54. The article of manufacture of claim 52 wherein the dynamic session information 
includes the entity's session ID. 

55. The article of manufacture of claim 51 wherein stq> (c) is performed by displaying a 
communications web page associated with the entity, the conununications web page reflecting 
the entity's current online presence and including hyperlinks to £3icilitate communication with the 
entity based on the entity's dynamic session informadon. 

56. The article of manu&cture of claim 55 wherein the communicadons web page is 
displayed as a result of the HTTP URL being typed into a web browser. 

57. The article of manufacture of claim 55 wherein the conununications web page is 
displayed as a result of clicking on or otherwise activating a hyperlink associated with the HTTP 
URL. 
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58. The article of manufacture of claim S 1 wherein multiple forms of communication 
with the entity are facilitated. 

59. The article of manufacture of claim 58 wherein the forms of conununication include 
type chat/instant messaging, voice communication over a computer networic» video 
communication over a computer network, voice communication firom a computer network to a 
telephone network and two-way text messaging to Internet enabled wireless devices. 

60. The article of manufacture of claim 5 1 wherein the static HTTP URL contains entity- 
selected information. 

61 . The article of manu&cture of claim 51 wherein the computer-executable instractions 
perform a method further comprising: 

(d) associating additional, different static HTTP URLs with the entity; 

(e) linking the additional URLs with the same communications information reflecting the 
entity's current online presence including the entity's dynamic session information as determined 
using the HTTP protocol; and 

(0 using the additional URLs and the communications information to fEicilitate 
communication with the entity. 

62* An article of manufacture for facilitating communication over a network with one or 
more members of a groiq> of entities, the groiqp ccnnprising a plurality of oitities, article of 
manu&cture cominisirig a computer-readable medium holding computer-executable instructions 
for performing a method comprising: 

(a) associating a static HTTP URL with the groiq^; 

(b) linking the URL with communications information reflecting each of the members' 
current online presence including each of the mraibers' dynamic session information as 
determined using the HTTP protocol; and 

(c) using the URL and the communications information to facilitate commtmication with 
one or more members of the group. 
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63. The article of manufacture of claim 62 wherein the dynamic session information 
includes each of the members' current dynamic IP address and host box identifier* 

64. The article of manufacture of claim 63 wherein the dynamic session information 
includes each of the members' TCP port number on which to be reached. 

65. The article of manufacture of claim 63 wherein the dynamic session information 
includes each of the members' session ID. 

66. The article of manufacture of claim 62 wherein step (c) is performed by displaying a 
communications web page associated widi the group, the communications web page reflecting 
each of the members' current online presence and including hyperlinks to facilitate 
communication with each of the members based on the members' dynamic session information. 

67. The article of manufacture of claim 66 wherein the communications web page is 
displayed as a result of the HTTP URL being typed into a web browser. 

68. The article of manufacture of claim 66 wherein the communications web page is 
displayed as a result of clicking on or otherwise activating a hyperlink associated with the HTTP 
URL. 

69. The article of manufacture of claim 62 wherein multiple forms of conununication 
with each of the members of the grotq> are facilitated. 

70. The article of manufacture of claim 69 wherein the forms of communication include 
type chat/instant messaging, voice communication over a computer networic, video 
communication over a computer network, voice ccmimunication from a computer networic to a 
telephone network and two-way text messaging to Internet enabled wireless devices. 

71 . The article of manufacture of claim 62 vdierein tfie static HTTP URL contains group- 
selected information. 
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72. The article of manufacture of claim 62 wherein the computer-executable instructions 
perform a method further comprising: 

(d) associating additional, different static HTTP URLs with the group; 

(e) linking the additional URLs with the same communications information reflecting 
each of the members* cuirent online presence including each of the members* dynamic session 
information as determined using the HTTP protocol; and 

(f) using the additional URLs and the communications information to facilitate 
communication with one or more members of the groiq>* 

73. An article of manufacture for detemiining the current online presence of an entity on 
a computer network, the article of manufacture comprising a computer-readable medium holding 
computer-executable instructions for perfomiing a method comprising: 

(a) associating a static HTTP URL with the entity; 

(b) linking the URL with conmnanications information reflecting the entity's cuirent 
online presence including the entity's dynamic session information as detemiined using the 
HTTP protocol; and 

(c) deteraaimng the cunrent online presence of ihc entity using Ike URL and the 
communications information. 

74. The article of manufacture of claim 73 wherein the dynamic session information 
includes the mtity's current dynamic IP address and host box identifier. 

75. The article of manufacture of claim 74 i^erein the dynaadc session information 
includes the entity^s TCP port number on which to be reached* 

76. The article of manu&cture of claim 74 wherein the dynamic session information 
includes the entity's session ID. 

77. The article of manufacture of claim 73 wherein the static HTTP URL contains entity- 
selected information. 
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78. An article of manufacture for detecting and maintaining an entity's current online 
presence on a computer network, the network including a host computer, the article of 
manufacture comprising a computer-readable medium holding computer-executable instructions 
for performing a method comprising: 

(a) sending an HTTP request from the entity to the host computer to initiate an HTTP 
connection between the entity and the host computer; 

(b) receiving the request at the host computer and opening and maintaining a socket for 
the HTTP coimection with the entity in a non-blocking manner without creating a new thread for 
the HTTP coimection; and 

(c) sending at least one byte of data from the host computer to the socket at a specified 
interval to keep open the HTTP connection with the entity. 

79. The article of manufacture of claim 78 Mdierein die computer-executable instructions 
perform a method further comprising: 

(d) checking the online status of the entity by polling the socket at a second specified 
interval to determine if the socket is open and deciding that the entity is still online if the socket 
is open and that the entity has gone offline if the socket is no longer open. 

80. The article of manufacture of claim 79 wherein the second specified interval is 4 
seconds. 

8 1 . The article of manufacture of claim 78 wherein the q^edfied interval is one minute. 

82. The article of manu£Eu:tuie of claim 78 wherein the specified interval is two minutes. 

83. The article of manufiK:ture of claim 78 herein the HTTP request is a GET request 

84. The article of manufacture of claim 78 vsdierein the computer-executable instructions 
perform a method further conq^rising: 
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(d) closing the socket at the host computer upon receiving a message from the entity that 
it is logging ofif of the network. 

85. An article of manufacture for detecting and maintaining the current online presence 
on a computer network of a plurality of entities, the network including a host computer, the 
article of manufacture comprising a computer-readable medium holding computer-executable 
instructions for performing a method comprising: 

(a) receiving a request at the host computer from one of the plurality of entities to 
establish an HTTP connection; 

(b) opening and maintaining a socket for the HTTP connection in a non-blocking manner, 
the socket having a socket file descriptor, with the one of the plurality of entities without creating 
a new thread for the HTTP connection; 

(c) adding the socket file descriptor to a socket database, the socket database maintaining 
a list of open sockets with those of the plurality of oitities that are currently online; and 

(d) sending at least one byte of data from the tost computer to ihc open sockets in the 
socket database at a specified interval to keq> open the HTTP connections with the plurality of 
entities. 

86. The article of manufacture of claim 85 wherein the computer-executable instructions 
perform a method further comprising: 

(e) checking the online status of the plurality of entities by polling the open sockets in the 
socket database at a second specified interval to determine if the open sockets are open and 
deciding that each of the plurality of entities is still online if its corresponding socket is open and 
that each of the plurality of entities has gone ofOine if its corie^nding socket is no longer op^ 

87. The article of manufiicture of claim 86 wherein the second specified interval is 4 
seconds. 

88. The article of manufacture of claim 85 wherein the specified interval is one minute. 

89. The article of manufacture of claim 85 v^rein the specified interval is two minutes. 
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90. The article of manufacture of claim 85 wherein the computer-executable instructions 
perform a method further comprising: 

(e) closing a socket at the host computer upon receiving a message from a corresponding 
one of the plurality of entities that it is log^g off of the network; and 

(f) removing the socket from the socket database. 

91 . An article of manufacture for sending text messages from a first entity to a second 
entity over a network using HTTP, the network including a host computer, the article of 
manufacture comprising a computer-readable medium holding computer^executable instructions 
for perfomiing a method comprising: 

(a) establishing and maintaining a socket and an HTTP connection between the second 
entity and the host computer; 

(b) sending a text message from the first entity to the host computer to be delivered to the 
second entity; 

(c) siding tfie text mes sage to the second entity from the host computer using the socket 
and the HTTP connection. 

92. The article of manufacture of claim 91 i^erein step (b) is performed by: 

(i) establishing and maintaining a second socl^ and a second HTTP connection between 
the first entity and the host computer, and 

(li) sending the text message from the first entity to the host computer using the second 
socket and the second HTTP connection. 

93. The article of manufacture of claim 92 wherein a reply message is sent from the 
second entity to the first entity, the computer-executable instructions performing a method 
further comprising: 

(d) sending a reply message from the second entity to the host computer using the socket 
and the HTTP connection; and 

(e) sending the reply message from the host computer to the first entity using the second 
socket and the second HTTP connection. 
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94. The article of manxifacture of claim 91 wherein the computer-executable instructions 
perform a method further comprising: 

(d) displaying the text message on the second entity. 

95. An article of manufacture for transporting SIP messages from a first entity to a 
second entity over a network, the network including a host computer, the article of manufacture 
comprising a computer*readable medium holding computer-executable instmctions for 
performing a method comprising: 

(a) establishing and maintaining a socket and an HTTP connection between the second 
entity and the host computer; 

(b) sending a SIP message from the first entity to tiie host computer to be delivered to the 
second entity; 

(c) sendit^ the SIP message to the second entity fix>m the host computer using &e socket 

96. The article of manufacture of claim 95 M^erein the computer-executable instructions 
perform a method further comprising: 

(d) sending a reply to the SIP message from the second entity to the host computer using 
an HTTP request. 

97. An article of manufacture for sending text messages from an entity to an Internet 
enabled wireless device over a networic, the network including a host computer, the article of 
manufactiu^e comprising a computer-readable medium holding computer-executable instmctions 
for performing a method comprising: 

(a) sending a communications request to the Internet enabled wireless device fiiom the 
host computer that includes an URL identifying the host conqiuter; 

(b) establishing and maintaining a socket and an HTTP coimection between the Internet 
enabled wireless device and the host computer using the URL; 

(c) sending a text messs^e from the entity to the host computer to be delivered to the 
Internet enabled wireless device; 
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(d) sending the text message to the Internet enabled wiieless device fiom the host 
computer using the socket and the HTTP connection. 

98. The article of manufiicture of claim 97 ^iierein step (c) is performed by: 

(i) establishing and maintaining a second socket and a second HTTP connection between 
the entity and the host computer; and 

(ii) sendii^ the text message from the entity to the host computer using the second socket 
and the second HTTP coimection. 

99. The article of manufacture of claim 98 wherein a reply message is sent from the 
Internet enabled wireless device to the entity, the computer-executable instructions performing a 
method further comprising: 

(e) sending a reply message from the Internet enabled wireless device to the host 
computer using the socket and the HTTP connection; and 

(0 sending the reply message from the host computer to the entity using the second 
socket and the second HTTP connection. 

100. The article ofmaniifacture of claim 97 \«dierdn the computer^^ 
instructions perform a method iiirlfaer comprising: 

(d) displaying tfie text messs^e on the Internet enabled wireless device. 

101 . A conq3Uter*implemented qiparatus for fru:ilitating communication with an entity 
over a networic. the appaxstas comprising: 

(a) means for associating a static HTTP URL with the entity; 

(b) means for linking the URL with communications information reflecting the entity's 
current online presence including the entity's dynamic session information as determined using 
the HTTP protocol; and 

(c) means for using the URL and the conununications infomiation to facilitate 
communication with the entity. 
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102. The apparatus according to claim 101 wherein the dynamic session information 
includes the entity's current dynamic IP address and host box identifier. 

103. The apparatus according to claim 102 wherein the dynamic session information 
includes the entity's TCP port number on which to be reached. 

1 04. The apparatus according to claim 102 wherein the dynamic session information 
includes the entity's session ID. 

105. TTie apparatus according to claim 101 wherein the means for using the URL and the 
communications information comprise means for displaying a communications web page 
associated with the entity, the communications web page reflecting the entity's current online 
presence and including hyperlinks to fiidlitate communication with the entity based on the 
entity's dynamic session information. 



106. The apparatus according to claim 105 wherein the communications web page is 
displayed as a result of the HTTP URL being typed into a web browser. 

107. The apparatus according to claim 105 wherein the communications web page is 
displayed as a result of clicking on or otherwise activating a hyperlink associated with the HTTP 
URL. 

1 08. The apparatus accoiding to claim 101 wherein multiple forms of communication 
widi the entity are i^icilitated. 

109. The appaiatas accordmg to daim 108 wdierein the forms of communication mclude 
type chat^nstant messaging, voice communication over a computer networic, video 
communication over a computer network, voice communication from a computer network to a 
telephone netwoik and two-way text messaging to Internet enabled wireless devices. 
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1 10. The apparatus according to claim 101 >vhereui the static HTTP URL contains 
entity-selected information. 

111. The apparatus according to claim 101 furth^ comprising: 

(d) means for associating additional^ different static HTTP URLs ivith the entity; 

(e) means for linking the additional URLs with the same communications information 
reflecting the entity^s cunrent online presence including the entity's dynamic session information 
as detemiined using the HTTP protocol; and 

(f) means for using the additional URLs and the communications infomiation to facilitate 
communication with the entity. 

112. A computer*implemented apparatus for facilitating conununication over a networic 
with one or more members of a group of entities, the group comprising a plurality of entities, the 
apparatus comprising: 

(a) means for associating a static HTTP URL with the group; 

(b) means for linking the URL with communications information reflecting each of the 
members' current online presence including each of the members' dynamic session information 
as determined using the HTTP protocol; and 

(c) means for using the URL ami the communications information to facilitate 
communication with one or more members of the group. 

1 13. The apparatus according to claim 1 12 herein the dynamic session information 
includes each of the members' current dynamic IP address and host box identifier. 

1 14. The q)paratus accordii^ to claim 1 13 wherein the dynamic session information 
includes each of the members' TCP port number on which to be reached. 

1 IS. The apparatus according to claim 113 wherein the dynamic session information 
includes each of the members' session ID. 
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116. The apparatus according to claim 1 12 wherein the means for using the URL and the 
communications information comprise means for displaying a communications web page 
associated with the group, the communications web page reflecting each of the members* cunent 
online presence and including hyperlinks to facilitate communication with each of the members 
based on the members* dynamic session information. 

1 1 7. The ^paratus according to claim 1 16 wherein tiie communications web page is 
displayed as a result of the HTTP URL being typed into a web browser. 

1 1 8. The ^aratus according to claim 1 16 wfaeron the communications web page is 
displayed as a result of clicking on or otherwise activating a hyperlink associated with the HTTP 
URL. 

119. The ^paiatus according to claim 1 12 wherein multiple forms of communication 
with each of the members of the group are facilitated. 

120. The apparatus according to claim 1 19 wherein the foratis of communication include 
type chat/instant messaging, voice communication over a computo network, video 
communication over a computer network, voice communication fiom a computer network to a 
telephone network and two-way text messaging to Internet enabled wireless devices. 

121. The apparatus according to claim 1 12 wfaeidn the static HTTP URL contains 
grotqj-selected information. 

122. The ^ypaiatus according to claim 1 12 further comprising: 

(d) means for associating additional, difiTetoit static HTTP URLs with the groiq); 

(e) means for linking the additional URLs with the same cmnmunications information 
reflecting each of die membeis* current online presence including eadi of the members* dynamic 
session inf(nmation as determined using the HTTP protocol; and 

if) means f<»- using die additional URLs and the conimumcati<»is information to facilitate 
commtmication widi one or mote members of the group. 
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123. A computer-implemented ^paratus for determining the current online presence of 
an entity on a computer network, the apparatus comprising: 

(a) means for associating a static HTTP URL with the entity; 

(b) means for linking the URL with communications information reflecting the entity's 
current online presence including the entity's dynamic session information as determined using 
the HTTP protocol; and 

(c) means for determining the current online presence of the entity using the URL and the 
communications information. 

124. The apparatus according to claim 123 wherein the dynamic session information 
includes the entity's current dynamic IP address and host box identifier. 

125. The apparatus according to claim 124 wherein the dynamic session information 
includes the entity's TCP port number on which to be reached. 

126. The apparatus according to claim 124 wherein the dynamic session information 
includes the entity's session ID. 

127. The apparatus according to claim 123 wherein the static HTTP URL contains 
entity-selected information. 

128. A computer-implemented ^paratus for detecting and maintaining an entity's 
current online presence on a computer networic, the network including a host computer, the 
apparatus comprising: 

(a) means for sending an HTTP request from the entity to the host computer to initiate an 
HTTP connection between the entity and the host compute^ 

(b) means for receiving the request at tiie host computer and opening and maintainii^ a 
socket for the HTTP coimection with the entity in a non-blocking maimer without creating a new 
thread for the HTTP coimection; and 



-51- 



wo 01/37139 



PCT/USOO/31601 



(c) means for sending at least one byte of data from the host computer to the socket at a 
specified interval to keep open the HTTP connection with the entity. 

129. The apparatus according to claim 128 further comprising: 

(d) means for checking the online status of the entity by polling the socket at a second 
specified interval to determine if the socket is open and deciding that the entity is still online if 
die socket is open and that the entity has gone offline if the socket is no longer open. 

130. The apparatus according to claim 129 vdierein the second specified interval is 4 
seconds. 

131. The apparatus according to claim 128 wherein the specified interval is one minute. 

132. The apparatus according to claim 128 wherein the specified interval is two minutes. 

133. The apparatus according to claim 128 wherein the HTTP request is a GET request 

134. The apparatus according to claim 128 fiurther comprising: 

(d) means for closing the socket at the host computer upon receiving a message fix>m the 
entity that it is logging off of die network. 

135. A computer-implemented apparatus for detecting and maintaining the current online 
presence on a computer networic of a plurality of entities, the network includmg a host computer, 
the qiparatus comprising: 

(a) means for receiving a request at the host con^iuter &om one of the plurality of entities 
to establish an HTTP connection; 

(b) means for opening and maintaining a socket for the HTTP connection in a non- 
blocking manner^ the socket having a socket file descriptor, with the one of the plurality of 
entities without creating a new thread for the HTTP connection; 
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(c) means for adding the socket file descriptor to a socket database, the socket database 
maintaining a list of open sockets with those of the plurality of entities that are ctinently online; 
and 

(d) means for sending at least one byte of data from the host computer to the open sockets 
in the socket database at a specified interval to keep open the HTTP connections with the 
plurality of entities. 

136. The sqsparatus according to claim 135 iiirther comprising: 

(e) means for checking the online status of the plurality of entities by polling the open 
sockets in the socket database at a second specified mterval to determine if the open sockets are 
open and deciding that each of the plurality of entities is still online if its coiresponding socket is 
open and that each of the plurality of entities has gone offline if its corresponding socket is no 
longer open. 

1 37. The ^paratus according to claim 136 wherein the second specified interval is 4 

seconds. 

1 38. The apparatus according to claim 135 wherein the specified interval is one minute. 

1 39. The apparatus accordmg to claim 135 wherein the specified interval is two minutes. 

140. The apparatus according to claim 135 further comprising: 

(e) means for closing a socket at the host computer upon receiving a message from a 
corresponding one of the plurality of entities that it is logging off of tfie network; and 
(0 means for removing the socket from the socket database. 

14 1 . A computer-implemented apparatus for sending text messages from a first entity to 
a second entity over a network using HTTP, the network including a host computer, the 
apparatus comprising: 

(a) means for establishing and maintaining a socket and an HTTP cormection between the 
second entity and the host computer; 
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(b) means for sending a text message from the first entity to the host computer to be 
delivered to the second entity; 

(c) means for sending the text message to the second entity from the host computer using 
the socket and the HTTP connection. 

142. The apparatus according to claim 141 \«iierein the means for sending a text message 
from the first entity to the host computer comprise: 

(i) means for establishing and maintaining a second socket and a second HTTP 
connection between the first entity and the host computer^ and 

(ii) means for sending the text mess^e from the first entity to the host computer using 
the second socket and the second HTTP connection. 

1 43. The apparatus according to claim 142 wherein a reply message is sent from the 
second entity to the first entity, the apparatus frirther comprising: 

(d) means for sending a reply message fix>m the second entity to the host computer using 
the socket and the HTTP connection; and 

(e) means for sending the reply message from the host computer to the fiist entity using 
the second socket and the second HTTP connection. 

144. The apparatus according to claim 141 further comprising: 
(d) means for displaying the text message on fte second entity. 

145- A computer-implemented a|iparatus for transporting SIP messages from a first 
entity to a second aitity over a netwoik, ibc network including a host computer, die apparatus 
comprising: 

(a) means for establishing and maintaining a socket and an HTTP connection between the 
second entity and die host computer; 

(b) means for sending a SIP message from the first entity to the host computer to be 
delivered to the second entity; 

(c) means for sending the SIP message to the second entity from the host computer using 
the socket 
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146. The apparatus according to claim 145 further comprising: 

(d) means for sending a reply to the SIP message from the second entity to the host 
computer using an HTTP request 

147. A computer-implemented apparatus for sending text messages from an entity to an 
Internet enabled wireless device over a network, the network including a host computer, the 
apparatus comprising: 

(a) means for sending a communications request to the Internet enabled wireless device 
from the host computer that includes an URL identifying the host computer, 

(b) means for establishing and maintaining a socket and an HTTP connection between the 
Interact enabled wireless device and the host computer using the URL; 

(c) means for sending a text message from the entity to the host computer to be delivered 
to the Internet enabled wireless device; 

(d) means for sending the text message to the Internet enabled wireless device from the 
host computer using the socket and the HTTP connection. 

148. The apparatus according to claim 147 wherein die means for sending a text message 
from the entity to the host computer comprise: 

(i) means for establishing and maintaining a second socket and a second HTTP 
connection between the entity and the host computer; and 

(ii) means for sending the text message from the entity to the host computer using the 
second socket and the second HTTP coimection. 

149. The apparatus accordii^ to claim 148 wherein a reply message is sent from the 
Internet enabled wireless device to the entity, the apparatus further comprising: 

(e) means for sending a reply message from the Internet enabled wireless device to the 
host computer using the socket and the HTTP connection; and 

(0 means for sending the reply message from the host computer to the entity using the 
second socket and the second HTTP connection. 
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(d) means for displaying the text message on the Internet enabled wireless device. 
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